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FOREWORD 


This  program,  contract  F33615-87-C-3216,  Project  2401  entitled  ASTROS  Enhancements,  had  four 
specific  goals: 

■  To  eiJaance  the  Automated  Structural  Optimization  System  (ASTROS)  by  providing 
new  features 

■  To  improve  those  already  in  place 

■  To  maintain  the  system 

■  To  determine  the  methods  of  releasing  the  system  to  public  users. 

The  program  included  six  broad  task  categories: 

■  Finite  Element  Library  Addition 

■  Aeroelastic  Analysis  Improvements 

■  Structural  Optimization  Methods 

■  Computational  Efficiency  Improvements 

■  Quality  Assurance 

■  Post-Processor  Interfaces 

These  tasks  were  performed  by  over  the  period  May  1987-May  1994  by  Universal  Analytics,  Inc. 
and  their  subcontractor,  the  Northrop  Corp. 

Please  note  that  the  three  volumes  of  User  documentation: 

■  ASTROS  User's  Manual 

■  ASTROS  Programmer's  Manaual 

■  ASTROS  Theoretical  Manual 

are  incorporated  into  this  document  by  reference.  There  is  no  attempt  to  cover  technical  details 
found  in  those  documents  (more  than  1500  pages)  nor  in  the  1000  pages  of  R&D  Status  Reports 
that  have  been  submitted  over  the  life  of  this  effort.  Rather,  the  following  sections  of  this  report 
summarize  each  of  the  work  items  performed  in  accomplishing  the  contract  tasks  and,  where 
appropriate,  present  some  highlights  of  the  development.  This  report  also  reviews  the  history  of 
the  program  through  Semi-Annual  Reviews,  Contract  Data  Requirements  and  ASTROS  system 
releases. 


TASK  1 .  FINITE  ELEMENT  LIBRARY 


Under  this  task,  UAI  was  to  perform  three  subtasks.  These  are: 


Contract 

Ref. 

TASK  NUMBER  AND  DESCRIPTION 

Effective 

Date 

3.1 

1.0  Finite  Element  Library 

22SEP87 

3.1.1 

1.1  Formulation  of  a  TRIAS  Element 

22SEP87 

3.1.2 

1.2  Rigid  Elements 

SPUN  P00007 
20NOV89 

3.1.5 

1.5  Automatic  SPC  Generator 

SPUN  P00021 
14SEP92 

Each  of  these  are  described  in  the  following  sections. 

1 .1  FORMULATION  OF  A  TRIA3  ELEMENT 

The  purpose  of  this  task  was  to  develop  a  three-noded  isoparametric  plate  and  shell  finite 
element  called  the  TRIAS.  This  element  is  the  companion  to  the  quadrilateral  QUAD4  element 
developed  by  UAI  imder  the  original  ASTROS  contract.  The  TRIAS  was  to  support  all  of  the 
QUAD4  features  including  variable  bending  propoerties  and  laminated  composites. 

In  2Q88  and  SQ88,  UAI  developed  the  theoretical  specification  of  the  TRIAS  element.  This 
specification  was  completed  during  4Q88  and  implementation  began.  The  formal  specification 
was  included  in  the  R&D  Status  Report  for  that  period. 

During  1Q89  and  2Q89  UAI  completed  the  coding,  implementation,  testing  and  installation  of 
the  new  TRIAS  finite  element.  While  performing  this  task,  various  minor  problems  in  the 
QUAD4  element  were  also  corrected.  The  results  of  the  element  accuracy  tests  for  both  elements 
are  presented  in  Table  1.  These  results  indicate  that  the  quality  of  the  new  ASTROS  elements 
rivals  that  found  in  the  commercially  available  NASTRAN  systems.  The  grade  scores  are  those 
defined  in  the  paper  "A  Proposed  Set  of  Problems  to  Test  Finite  Element  Accuracy"  by  MacNeal 
and  Harder  (Finite  Elements  in  Analysis  and  Design,  No.  1,  North-Holland,  Amsterdam,  1985). 

1.2  RIGID  ELEMENTS 

The  purpose  of  this  task,  added  under  the  contract  modification  of  20  November  1989,  was  to 
implement  the  rigid  elements  REAR,  RROD,  RBEl  and  RBE2  into  ASTROS  in  order  to  simplify 
the  definition  of  multipoint  constraints  which  now  require  the  laborious  preparation  of  MPC 
data  entries.  This  task  began  in  4Q89  with  the  development  of  the  executive  and  user  interfaces 
to  these  features.  By  1Q95,  these  elements  had  been  installed  into  the  ASTROS  development 
system,  and  they  were  undergoing  full  integrated  testing. 

Highlights  of  the  rigid  element  development  included  detailed  error  checking  which  improves 
on  that  found  in  the  test  comparator,  MSC /NASTRAN.  Unlike  NASTRAN,  the  ASTROS  rigid 
elements  may  be  selected  using  the  MPC  parameter  on  the  BOUNDARY  Solution  Control  com¬ 
mand.  This  has  generalized  the  rigid  elements  in  the  same  manner  as  MPC  equations  —  they 
may  be  changed  from  boundary  condition  to  boundary  condition.  This  feature  is  imperative  in 
the  multidisciplinary  design  process. 
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TEST 

ELEMENT  LOADING 

ELEMENT 

SHAPE 

QUAD4 

TRIA3 

IN-PLANE 

OUT-OF¬ 

PLANE 

1.  PATCH  TEST 

■ 

■ 

IRREGULAR 

A 

A 

2.  STRAIGHT  BEAM,  EXTENSION 

■ 

ALL 

A 

A 

3.  STRAIGHT  BEAM,  BENDING 

■ 

REGULAR 

B 

F 

4.  STRAIGHT  BEAM,  BENDING 

■ 

IRREGULAR 

F 

F 

5.  STRAIGHT  BEAM,  BENDING 

■ 

REGULAR 

A 

B 

6.  STRAIGHT  BEAM,  BENDING 

■ 

IRREGULAR 

A 

B 

7.  STRAIGHT  BEAM,  TWIST 

■ 

ALL 

B 

F 

8.  CURVED  BEAM 

■ 

REGULAR 

C 

F 

9.  CURVED  BEAM 

■ 

REGULAR 

B 

B 

10.  TWISTED  BEAM 

■ 

■ 

REGULAR 

A 

B 

11.  RECTANGULAR  PLATE 

■ 

REGULAR 

A 

B 

12.  SCORDELIS-LO  ROOF 

■ 

■ 

REGULAR 

B 

D 

13.  SPHERICAL  SHELL 

■ 

■ 

REGULAR 

A 

B 

14.  THICK  WALLED  CYLINDER 

■ 

REGULAR 

B 

A 

UAI  completed  comprehensive  testing  in  2Q95,  and  the  new  elements  were  made  available  in 
the  ASTROS  Version  6  release. 

1 .3  AUTOMATIC  SPC  GENERATOR 

Task  1.5  was  added  imder  the  contract  modification  of  14  September  1992.  The  purpose  of  this 
task  was  to  develop  an  Automatic  SPC  generator  comparable  to  those  fovmd  in  commercial 
finite  element  products.  This  feature  is  a  user  convenience  which  simplifies  modeling.  Design 
work  began  in  1Q93.  Then,  at  the  request  of  COTR,  work  was  accelerated  to  assist  the  Govern¬ 
ment  in  providing  more  features  for  aerospace  companies  using  ASTROS  for  the  HSCT  pro¬ 
gram.  The  implementation  and  testing  were  completed  during  2Q93,  and  the  feature  was 
delivered  on  1  October  1993  as  part  of  the  ASTROS  Version  10.5  interim  system. 
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TASK  2.  AERODYNAMICS 


Under  this  task,  UAI  was  to  perform  10  subtasks.  These  are: 


Contract 

Ref. 

TASK  NUMBER  AND  DESCRIPTION 

Effective 

Date 

3.2.1 

2.1  Aerodynamic  Influence  Coefficients  for  Bodies 

22SEP87 

3.2.2 

2.2  Eliminating  Fixed  Size  Arrays 

22SEP87 

2.3  Nonplanar  Boundary  Condition  Option 

22SEP87 

2.4  Control  Surface  with  Inset  Tabs 

22SEP87 

2.5  Control  Surface  Effectiveness 

22SEP87 

2.6  Linear  Spline 

22SEP87 

3.2.7 

2.7  New  Aeroelastic  Constraints  —  RoU  Rate  Constraint,  Pitch  Rate 
Constraint,  Control  Surface  Constraint 

SPUN  P00007 
20NOV89 

3.2.11 

2.11  Fast  Fourier  Transform 

SPUN  P00021 
14SEP92 

Each  of  these  are  described  in  the  following  sections. 

2.1  BASIC  AERODYNAMIC  ENHANCEMENTS 

Under  the  original  enhancements  contract,  five  new  features  were  to  be  developed: 

■  2.1  Aerodynamic  Influence  Coefficients  for  Bodies 

■  2.2  Eliminating  Fixed  Size  Arrays 

■  2.3  Nonplanar  Boimdary  Condition  Option 

■  2.4  Control  Surface  with  Inset  Tabs 

■  2.5  Control  Surface  Effectiveness 

Work  on  these  tasks  commenced  in  3Q88.  Two  work  items  were  performed:  the  development  of 
the  Functional  and  Theoretical  Specifications  for  the  new  enhancements,  and  an  outline  of  the 
approach  to  be  used  in  removing  the  fixed-size  arrays  from  the  USSAERO  module  of  ASTROS. 

During  4Q88,  the  work  on  the  aerodynamics  enhancements  focussed  on  the  elimination  of  the 
fixed-size  arrays  in  the  USSAERO-based  steady  aerodynamics  module.  The  analysis  of  the 
source  code  showed  that  32  common  blocks,  each  with  several  fixed  dimension  arrays,  needed 
to  be  replaced  by  the  ASTROS  dynamic  memory  utilities.  The  task  of  replacing  these  arrays  was 
not  as  straight-forward  as  originally  supposed  because  the  data  needed  to  determine  the  amount 
of  memory  to  allocate  was  not  always  available.  This  resulted  in  the  coding  of  two  new  routines 
that  compute  the  dimensioning  data  directly  from  the  input  data  stream  prior  to  performing  the 
actual  geometry  and  panelling  operations. 

During  1Q89,  the  removal  of  the  fixed-size  arrays  in  the  USSAERO-based  steady  aerodynamics 
module  was  completed.  Several  test  cases  were  used  to  demonstrate  that  the  resulting  code  was 
fimctioning  correctly.  The  new  code  was  made  available  in  the  Version  4  ASTROS  system. 
Additionally,  the  functional  specifications  and  most  of  the  theoretical  specifications  for  the  re- 
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maining  aerodynamic  enhancements  have  been  completed.  An  extensive  study  of  the  ASTROS 
aeroelastic  features  has  led  to  a  development  plan  which  adds  all  new  capabilities  and,  at  the 
same  time,  makes  all  features  more  consistent. 

During  2Q89  and  3Q89  all  of  the  aeroelastic  enhancements,  with  the  exception  of  the  nonplanar 
boimdary  condition  option,  were  completed  and  tested.  Northrop  experienced  several  difficul¬ 
ties  in  implementing  the  nonplanar  boundary  condition  option.  The  principal  difficulty  encoxm- 
tered  was  that  the  nonplanar  option  in  the  version  of  USSAERO-C  that  Northrop  used  as  a 
reusable  code  resource  was  in  error.  This  was  illustrated  by  using  both  the  planar  and  nonplanar 
options  for  a  thin  airfoil.  Although  the  results  of  these  two  cases  should  have  been  comparable, 
there  were  significant  differences. 

During  4Q89,  it  was  determined  that  ASTROS  matched  the  nonplanar  solution  of  UASSAERO-C 
thus  ending  this  task.  All  of  the  aerodynamic  features  were  made  available  to  the  public  in 
Version  5.0  of  ASTROS. 

2.2  LINEAR  SPLINE 

During  2Q89,  the  linear  SPLESTEl  element  of  COSMIC  NASTRAN  was  partially  incorporated 
into  the  ASTROS  spline  module.  Completion  required  the  addition  of  the  ASTROS  steady  aero- 
d5mamic  macroelements  which  were  not  part  of  the  original  COSMIC  NASTRAN.  These  fea¬ 
tures  were  completed,  and  during  3Q89,  the  spline  implementation  was  completed. 

2.3  NEW  AEROELASTIC  CONSTRAINTS 

The  new  contract  modifications  of  20  November  1989  added  three  new  work  items  related  to  the 
ASTROS  aerodynamics  capability.  These  were: 

■  Roll  rate  constraint  definition  and  sensitivities 

■  Pitch  rate  constraint  definition  and  sensitivities 

■  Control  surface  deflection  constraint  definition  and  sensitivities 

UATs  subcontractor,  Northrop  Corp.,  developed  the  theoretical  and  hmctional  specifications  for 
these  features  during  1Q90.  During  2Q90,  Northrop  completed  the  implementation  of  these 
features.  Two  new  constraint  definition  Bulk  Data  entries  were  added  to  ASTROS  which  allow 
the  user  to  constrain  any  number  of  aerod5mamic  parameters  and/ or  stability  coefficients.  This 
provided  all  of  the  capabilities  specified  above  in  a  manner  fully  consistent  with  the  other 
ASTROS  aerodynamic  constraints. 

The  first  new  constraint  is  defined  by  DCONTRM  data.  It  allows  the  user  to  place  upper  and/ or 
lower  bound  constraints  on  any  of  the  trim  variables  when  performing  and  ASTROS  steady 
aeroelastic  trim  analysis.  Thus,  the  user  can  constrain  any  control  surface  deflection,  trim  pa¬ 
rameter,  (angle  of  attack,  yaw  angle,  roll  rate,  pitch  rate,  yaw  rate)  and/or  any  component  of  the 
structural  acceleration  at  the  support  point.  The  actual  number  of  parameters  that  can  be  con¬ 
strained  by  DCONTRM  is  unlimited,  since  the  user  may  define  an  unlimited  number  of  control 
surfaces. 

The  second  type  of  constraint  is  defined  by  DCONSCF  Bulk  Data.  It  allows  the  user  to  place 
upper  and/or  lower  bormd  constraints  on  any  or  all  of  the  flexible  stability  derivatives  at  the 
reference  grid  point.  When  using  this  feature,  the  user  is  actually  defining  a  limiting  value  for 
the  FLEXIBLE  quantities  in  the  TRIM  table. 
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These  two  new  constraints,  combined  with  those  already  available,  provide  a  comprehensive 
suite  of  constraints  on  the  aeroelastic  performance  of  the  vehicle.  Two  possible  applications  of 
these  new  features  are  to  optimize  for  a  particular  level  of  longitudinal  stability  (quantified  as 
the  flexibility  stability  coefficient  for  pitch  moment  due  to  angle  of  attack),  and/or  to  optimize 
for  a  particular  positive,  zero,  or  negative  control  surface  effectiveness.  This  latter  feature  is  a 
generalization  of  the  current  aileron  effectiveness  constraint  but  makes  no  assumptions  about 
the  axis  of  interest. 

2.4  FFT  WITH  RANDOM  INPUT 

Under  the  contract  modification  of  14  September  1992,  a  new  task  was  added  to  the  effort  to 
implement  a  Fast  Fourier  Transform  algorithm  to  facilitate  time  and/or  frequency  domain 
analysis  with  random  inputs.  The  first  part  of  this  task  required  a  comprehensive  evaluation  of 
the  existing  software.  A  number  of  test  cases  were  developed  for  both  time  and  frequency 
domain  analyses.  These  were  executed  and  vmcovered  a  number  of  errors  which  primarily 
related  to  the  communication  between  the  FFT  subroutines  and  the  MAPOL  sequence. 

While  the  FFT  algorithm  itself  was  functioning  properly,  these  errors  in  the  generation  of  time 
loadings  and  frequency  lists,  led  to  failure  of  the  test  cases.  Additionally,  there  were  errors  in  the 
handling  of  frequency  response  solution  vectors  both  prior  to  and  after  the  inverse  FFT  was 
applied.  All  of  these  errors  were  identified  and  corrected.  The  final  status  of  this  capability 
shows  that  it  functions  properly  under  certain  circumstances,  but  there  are  still  problems  that 
require  future  correction. 
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TASK  3.  OPTIMIZATION 


Under  this  task,  UAI  was  to  perform  six  subtasks.  These  are: 


Contract 

Ref. 

TASK  NUMBER  AND  DESCRIPTION 

Effective 

Date 

3.3 

3.0  Optimality  Criterion  Methods 

22SEP87 

3.3.1 

3.1  Generalized  Stiffness  Constraint 

SPUN  P00011 
28SEP90 

3.3.2 

3.2  Stress /Strain  Constraints 

SPUN  P00011 
28SEP90 

3.3.3 

3.3  Bending  Element  Optimization 

SPUN  P00021 
14SEP92 

3.3.4 

3.4  Buckling  Optimization 

SPUN  P00021 
14SEP92 

3.3.5 

3.5  User  Defined  Objective  Function,  Constraint  and  Sensitivity 

SPUN  P00021 
14SEP92 

3.3.6 

3.6  Composite  Laminate  Constraints 

SPUN  P00021 
14SEP92 

Each  of  these  are  described  in  the  following  sections. 

3.1  OPTIMALITY  CRITERION  METHODS 

The  purpose  of  this  task  was  to  implement  govemment-fumished  software  which  performs 
structural  optimization  based  on  the  Optimality  Criterion  Methods.  This  new  method  was  in¬ 
tended  to  supplement  the  original  optimization  methodology  based  on  Mathematical  Program¬ 
ming. 

This  task  proved  to  be  the  most  problematic  of  those  performed  tmder  this  effort.  Under  the 
original  contract,  UAI  was  to  design,  code,  and  test  Optimality  Criteria  methods  within  AS¬ 
TROS.  The  contract  modification  dated  28  September  1990  then  changed  the  task  significantly. 
Under  the  modification,  UAI  became  responsible  for  installing  and  testing  optimization  software 
provided  as  GEE  by  the  Air  Force.  While  a  portion  of  this  software  was  transmitted  to  UAI  by 
COTR  on  17  November  1989,  it  was  not  sufficient  to  perform  the  required  implementation 
activities.  The  schedule  for  this  task  was  thus  deferred  iintil  the  arrival  of  all  required  software. 

UAI  received  the  GFE  Optimality  Criteria  software  in  late  July  1990  and  transmitted  a  copy  to 
Northrop  in  early  August.  Northrop  studied  the  software  documentation  and  source  code  and 
designed  an  documented  and  interface  to  allow  its  integration  into  ASTROS.  This  interface  was 
then  coded  and  tested.  Northrop  was  unable  to  achieve  convergence  for  any  of  the  standard 
ASTROS  Application  Manual  test  problems.  Consultation  with  the  Air  Force  software  develop¬ 
ers  indicated  that  the  convergence  problem  was  due  to  the  new  GFE  software,  not  the  baseline 
ASTROS  system.  The  code  developed  to  interface  the  GFE  software  was  sent  to  the  Air  Force  to 
assist  them  in  developing  a  working  algorithm.  Further  work  has  been  halted  pending  the 
delivery  of  an  upgraded  version  of  the  GFE  software  from  WRDC.  This  difficulty  again  required 
modifications  to  die  Program  Schedule. 

During  4Q90,  Northrop  reorganized  the  main  driver  routine,  called  VANGO,  to  make  it  fully 
compatible  with  ASTROS,  and  modified  the  standard  MAPOL  sequence  to  use  the  new  optimal- 
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ity  criteria  method  within  ASTROS,  either  alone  or  in  combination  with  the  other  optimization 
options.  Solution  control  was  modified  to  allow  user  control  of  this  feature.  All  other  work  was 
suspended  pending  the  delivery  of  an  upgraded  version  of  the  GFE  software  from  the  Govern¬ 
ment. 

In  2Q94,  COTR  indicated  that  upgrades  to  the  GFE  Optimality  Criteria  software  would  not  be 
forthcoming.  Thus,  Task  3.0  was  completed  per  the  implementation  described  above. 

3.2  GENERALIZED  STIFFNESS  CONSTRAINT 

The  purpose  of  this  task  was  to  implement  a  generalized  stiffness  constraint,  provided  by  the 
Government,  in  ASTROS.  The  generalized  stifftress  constraint  is  intended  to  be  used  with  the 
optimality  criterion  methods  described  in  the  previous  section.  The  intent  of  this  feature  is  to 
improve  performance  by  reducing  the  number  of  stress  constraints  used  during  optimization. 
UAI  completed  the  preliminary  implementation  of  this  constraint  during  1Q92.  The  technique 
did  not  yield  acceptable  results,  and  interim  test  data  was  delivered  to  the  Government  for 
evaluation.  Work  has  halted  pending  this  investigation.  While  the  basic  method  employed 
would  have  resulted  in  potential  savings  during  optimization,  the  stability  of  the  technique 
proved  unacceptable  and  further  work  was  abandoned. 

3.3  STRESS/STRAIN  CONSTRAINTS 

The  purpose  of  this  task  was  to  improve  the  methods  used  for  specifying  stress  and  strain 
constraints  in  ASTROS.  The  initial  implementation,  which  followed  that  used  by  a  commercial 
vendor,  proved  to  be  ambiguous.  This  occurred  because  all  material  allowables  have  been  de¬ 
fined  on  a  MATi  Bulk  Data  entry.  The  tension,  compression  ands  shear  allowables  are  thus 
applied  to  either  the  stresses  or  the  strams,  but  not  both.  There  was  no  alternate  method  which 
allowed  constraints  to  be  applied  both  types  of  responses.  The  sections  below  outline  the  modifi¬ 
cations  that  UAI  made  to  remove  this  restriction.  Basically,  separate  constraints  were  allowed  for 
each  response  type,  and  two  forms  of  strain  constraints  were  implemented. 

Two  additional  important  extensions  were  also  made.  Firstly,  the  constraints  were  allowed  to  be 
selectable  by  analysis  case.  This  allows  a  design  to  satisfy  multiple  sets  of  allowables  which 
represent,  for  example,  damage  or  hot/wet  environments.  Secondly,  the  constraints  may  be 
selected  by  either  element  identification  number  or  by  element  property  identification  number. 
This  feature  greatly  simplifies  input  for  modest  numbers  of  constraints.  The  original  method 
only  supported  the  definition  of  these  constraints  by  material  identification  number. 

The  original  Von  Mises  stress  constraint  and  Tsai-Wu  stress  constraint  were  modified  for  these 
changes.  Additionally,  two  new  Bulk  Data  entries  were  added  to  ASTROS  to  implement  both 
the  principal  strain  allowables,  favored  by  Northrop,  and  the  fiber  and  transverse  strain  allow¬ 
ables  favored  by  General  Dynamics.  In  the  first  case,  these  data  are  defined  by  the  strain  limits 
for  tension,  compression,  and  shear,  respectively.  In  the  second,  they  are  defined  by  the  tension 
and  compression  strain  limits  in  both  the  fiber  direction  and  the  transverse  direction. 

All  of  the  improved  methods  used  for  specifying  stress  and  strain  constraints  in  ASTROS  were 
included  for  release  in  Version  8.0. 
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3.4  BENDING  ELEMENT  SENSITIVITY 


The  purpose  of  this  task  was  to  expand  the  ASTROS  optimization  capability  to  bending  ele¬ 
ments.  To  do  this  required  a  significant  reengineering  of  the  software.  ASTROS  originally  as¬ 
sumed  that  all  design  variables  would  be  result  in  factorable  mass  and  stiffness  matrices.  That  is, 
that  the  design  variables,  such  as  membrane  thickness  and  bar  cross-sectional  area  could  be 
factored  out  of  the  element  stiffness  matrices.  As  a  result,  design  sensitivities  were  available 
analytically.  Under  this  task,  it  was  necessary  to  remove  this  restriction  and  compute  sensitivi¬ 
ties  of  nonlinear  design  variables,  such  as  plate  bending  thicking,  semi-analytically  using  finite 
difference  methods. 

Preliminary  design  work  on  this  major  new  capability  was  begun  in  4Q92.  The  level  of  effort 
was  reduced  over  the  next  several  quarters  due  to  fimding  allocation  delays.  However,  by  2Q93 
the  comprehensive  preliminary  design  document  was  completed  and  delivered  as  part  of  the 
R&D  Status  Report  for  that  period. 

Late  fxmding  allocations  then  reduced  the  level  of  effort  imtil  2Q94  when  the  initial  implementa¬ 
tion  was  made.  Comprehensive  unit  and  integrated  testing  was  performed.  Numerous  errors 
were  detected  which  required  significant  labor  to  analyze  and  correct.  This  occurred  because  of 
the  large  number  of  major  infrastructural  changes  made  to  ASTROS  to  support  this  capability. 
These  changes  "touched"  so  many  areas  of  the  system  that  many  test  cases  had  to  be  formulated 
and  executed  to  insure  that  the  new  capability  ftmctioned  propoerly,  and,  that  it  had  not  dis¬ 
abled  any  other  parts  of  the  program. 

UAI  added  an  important  additional  work  item  required  vmder  this  task  to  handle  design  vari¬ 
able  coupling  for  the  BAR  element.  The  initial  ASTROS  design  assumed  that  there  was  an 
exponential  relationship  between  the  cross-sectional  area  and  moments  of  inertia  for  such  ele¬ 
ments.  This  crude  approximation  allowed  the  computation  of  analytical  sensitivities  in  the  origi¬ 
nal  design  but  was  found  to  be  totally  inadequate  in  modeling  design  degrees  of  freedom.  UAI 
suggested,  and  COTR  agreed,  that  the  "PBARl"  technique  developed  by  UAI  for  other  purposes 
would  solve  this  problem.  The  PBARl  approach  allows  users  to  define  the  actual  cross-sectional 
geometry  of  elements  based  on  geometric  parameters.  These  parameters,  which  then  become  the 
physical  design  variables,  can  be  used  to  compute  the  dependent  BAR  parameters  —  area  and 
moments  of  inertia.  As  a  result,  all  of  the  design  degrees  of  freedom  are  correctly  modeled  and 
the  stiffness,  mass,  and  element  responses  are  consistent,  and  they  can  be  handled  during  the 
design  process. 

The  implementation  of  the  PBARl  was  also  significantly  more  difficult  than  originally  thought. 
An  original  design  axiom  of  ASTROS  was  that  each  finite  element  would  have  only  a  single 
design  variable.  Because  the  PBARl  allows  elements  to  have  from  1  to  10  design  variables,  this 
axiom  was  broken.  To  change  the  old  computational  paradigm  required  the  modification  of 
many  more  subroutines  and  data  structures  than  originally  anticipated. 

During  the  3Q94,  the  processing  of  design  variable  coupling  for  the  BAR  element  was  com¬ 
pleted.  Comprehensive  unit  and  integrated  testing  have  been  performed  with  excellent  results. 
A  small  number  of  tests  relating  to  the  PBARl  remained.  All  further  testing  and  error  correction 
was  performed  during  4Q94  and  1Q95,  and  the  completed  capability  released  in  ASTROS  ver¬ 
sion  12.0. 
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3.5  BUCKLING  OPTIMIZATION 


The  purpose  of  this  task,  added  imder  the  contract  modification  of  14  September  1992,  was  to 
develop  local  buckling  constraints  for  stiffened  panels.  Work  began  in  2Q93,  when  the  prelimi¬ 
nary  design  specifications  were  prepared.  The  task  was  to  proceed  in  three  phases  as  described 
below. 

The  first  phase  was  the  implementation  of  the  unstiffened  panel  buckling.  This  was  completed 
during  3Q93  and  4Q93,  and  preliminary  testing  showed  good  results. 

The  second  and  third  phases  were  implemented  and  tested  during  4Q93.  The  second  phase  was 
the  installation  of  the  Euler  column  buckling  for  ROD  and  BAR  elements.  This  procedure  was 
similar  to  that  already  implemented  for  the  xmstiffened  panel  buckling,  i.e.  a  single  control 
element  is  selected  and  its  load  applied  to  the  "logical"  beams  defined  by  the  user.  Inertia  linking 
during  the  design  is  accomplished  using  the  usual  power  law  as: 

I  =  r  ■ 

A  test  case  was  nm  to  verify  the  capability.  The  problem  selected  was  the  25  bar  truss  as  defined 
in  the  MSC  Design  Optimization  Handbook.  The  ASTROS  results  were  very  similar,  but  the 
members  that  are  resized  to  their  minimum  size  were  slightly  larger  in  ASTROS.  This  is  because 
of  the  nonlinearity  of  the  eigenvalue  which  is  only  being  approximated  in  ASTROS,  while 
MSC/NASTRAN  is  using  fimction  evaluation  to  obtain  a  higher-order  approximation  to  the 
correct  nonlinear  behavior. 

The  third  phase  was  the  implementation  of  the  panel  buckling  capabilty  for  PSHELL  properties. 
This  was  accomplished  by  assuming  a  relationship  between  the  bending,  membrane  and  trans¬ 
verse  shear  properties  of  the  element.  The  feature  was  verified  by  solving  the  ICW  model. 

The  completed  capability,  including  all  of  the  options  described  above,  was  delivered  in  Version 
11.0  ASTROS. 

3.6  USER  DEFINED  OBJECTIVE  FUNCTION,  CONSTRAINT  AND  SENSITIVITY 

The  purpose  of  this  task,  added  under  the  contract  modification  of  14  September  1992,  was  to 
allow  arbitrary  functional  forms  for  design  constraints,  and  the  objective  function,  within  AS¬ 
TROS. 

The  initial  design  of  this  capability  was  begim  in  2Q93.  The  design  was  completed  in  3Q93  and 
presented  in  the  R&D  Status  Report  for  that  period.  Ehiring  4Q93  the  language  compiler  needed 
to  interpret  the  user  fimctions,  and  to  compute  the  necessary  derivatives  for  sensitivity  analysis 
were  implemented.  The  implementation  of  the  capability  into  ASTROS  proved  to  be  more  time 
consuming  than  originally  estimated  due  to  the  major  infrastructural  changes  required  to  the 
ASTROS  software  architecture. 

Specifically,  in  order  to  evaluate  the  functions  and  their  corresponding  derivatives,  it  was  neces¬ 
sary  to  gather  numerical  values  and  terms  from  numerous  areas  within  ASTROS.  This  resulted 
in  the  modification  of  many  modules.  The  basic  implementation  of  this  major  new  capability 
was  completed  in  3Q94  and  comprehensive  unit  and  integrated  testing  began.  The  testing  was 
also  significant  because  of  the  pervasiveness  of  the  major  changes  made  to  ASTROS  to  support 
this  capability. 

A  hiatus  of  several  months  occurred  due  to  lateness  of  funding  authorization.  Additionally,  this 
task  required  more  human  resources  than  originally  estimated.  This  is  not  surprising  given  the 
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high  technological  risk  associated  with  this  task.  The  capability  was  completed  during  4Q94  and 
1Q95  and  was  delivered  with  the  final  Version  12.0  ASTROS  system. 

3.7  COMPOSITE  LAMINATE  CONSTRAINTS 

The  purpose  of  this  task,  added  under  the  contract  modification  of  14  September  1992,  was  the 
development  and  installation  of  manufacturing  constraints  for  composite  materials.  A  new  set  of 
design  constraints  were  defined  to  handle  the  common  composite  manufacturing  requirements 
that  are  applied  during  the  design  of  structures  using  composite  laminates.  These  constraints  are 
on:  the  ply  minimum  gauge;  the  laminate  minimum  gauge;  and  the  percentage  of  the  laminate 
that  is  made  up  of  a  ply.  Together  with  the  use  of  design  variable  linking  and  side  constraints  on 
both  the  local  and  global  design  variables,  these  constraints  allow  the  user  to  ensure  that  the 
optimization  process  will  generate  a  thickness  distribution  that  is  at  least  reasonably  close  to  a 
manufacturable  laminate.  Of  course,  the  restriction  of  a  continuous  design  variable  approxima¬ 
tion  to  the  discrete  layer  thicknesses  is  still  present. 

The  new  constraints  are  defined  using  the  DCONPMN,  DCONLMN  and  dconlam  Bulk  Data  entries 
to  define  ply  minimum  gauge,  laminate  minimum  gauge  and  laminate  composition  constraints, 
respectively.  The  laminate  composition  constraints  allow  the  specification  of  an  upper  or  lower 
boimd  on  the  percentage  of  a  laminate  thickness  that  is  composed  of  a  particular  ply  thickness. 
The  other  two  constraints  are  self-evident. 

All  three  constraints  share  common  definitions  of  the  ply  and  the  laminate,  which  are  worthy  of 
some  discussion.  A  ply  consists  of  one  or  more  layers  whose  summed  thicknesses  will  constitute 
the  ply  thickness.  Similarly,  a  laminate  is  one  or  more  layers  whose  summed  thicknesses  will 
constitute  the  total  laminate  thickness.  A  "layer"  is  one  MID/THETA/T  combination  on  either  a 
PCOMP,  PCOMPl  or  PCOMP2  entry.  The  principal  difference  between  a  ply  and  a  laminate  is  that 
the  defaults  are  set  up  to  allow  simple  input  when  a  ply  is  a  single  layer  and  when  a  laminate 
consists  of  all  layers. 

The  generality  of  the  ply  and  the  laminate  definitions  provides  for  the  generality  of  the  typical 
composite  composition  constraints.  For  example,  there  are  usually  both  lower  and  upper  boxmd 
fractions  of  the  laminate  thickness  for  each  distinct  fiber  orientation.  These  orientations  may  be 
(and  usually  are)  separated  into  noncontiguous  layers  on  the  PCOMP  entry.  Therefore,  the  ply 
definition  needs  to  be  all  layers  with  the  same  orientation  and  not  just  a  single  layer.  For 
sandwich  composites  with  composite  face  sheets,  each  face  sheet  independently  has  the  manu¬ 
facturing  composition  constraint  imposed  and  the  core  thickness  and  the  other  face  sheet  are  not 
desired  in  the  definition  of  the  laminate  thickness.  All  these  scenarios  are  accommodated  in  the 
ASTROS  constraint  definitions. 

Under  certain  definitions  of  ply  or  laminate  minimum  gauge,  the  DCONPMN  or  DCONLMN  are 
redundant  with  the  side  constraint  on  the  local  design  variable.  This  will  be  the  case  if  the  ply  or 
laminate  consists  of  only  one  layer.  The  installation  of  these  constraints  into  ASTROS  accounts  for 
this  circumstance  by  comparing  the  minimum  gauge  against  the  TMIN  field  of  the  associated 
connectivity  entry  if  SHAPE  linked  or  against  the  computed  TMIN  =  (VMIN^initial  value)  if 
physically  linked.  The  most  critical  gauge  limit  among  all  DCONPMN,  DCONLMN  and  TMIN  values 
will  be  used  to  update  the  side  constraint  value  and  the  DCONPMN  and/ or  DCONLMN  will  be 
disabled  (since  they  are  now  redimdant).  A  table  of  these  actions  is  printed  to  the  output  file  to 
inform  the  user  that  ASTROS  has  replaced  some  user-defined  constraints. 

In  defining  the  composite  manufacturing  constraints,  a  PLYLIST  Bulk  Data  entry  was  devel¬ 
oped  to  define  the  plies  that  compose  the  ply  or  laminate.  With  the  creation  of  this  input  entry,  it 
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was  decided  to  make  use  of  it  in  all  aspects  of  the  design  model.  The  DESVARP  and  DESVARS 
entries  were  therefore  modified  to  reference  PLYLIST  sets  instead  of  the  SETl  entries  that  were 
originally  used.  Updating  older  models  involves  changing  the  name  SETl  to  PLYLIST  for  all 
SETl  entries  that  are  ply  lists  referenced  by  DESVARP  or  desvars.  The  input  format  is  other¬ 
wise  unchanged. 

Finally,  the  DCONTHK  entry  was  augmented  with  a  DCONTH2  entry.  Functionally,  it  is  the  same 
as  the  DCONTHK  except  that  it  allows  the  selection  of  thickness  constraints  at  the  layer-level 
rather  than  the  element-level.  Under  DCONTHK  entries,  the  thickness  constraints  of  all  layers  of  a 
composite  are  retained  as  active.  Under  DCONTH2,  only  those  layers  that  are  called  out  are 
retained.  This  avoids  the  problems  that  can  occur  with  many  redxmdant  constraints  (same  con¬ 
straint  value  and  identical  sensitivities).  This  problem  occurs  frequently  when  the  design  vari¬ 
able  linking  is  enforcing  a  symmetry  condition:  each  layer  thickness  is  treated  as  an  independent 
constraint  when,  in  fact,  the  layers  across  the  plane  of  symmetry  are  identical  constraints. 
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TASK  4.  COMPUTATIONAL  EFFICIENCY 


Under  this  task,  UAI  was  to  perform  six  subtasks.  These  are: 


Contract 

Ref. 

TASK  NUMBER  AND  DESCRIPTION 

Effective 

Date 

3.4.1 

4.1  Timing  Analysis 

22SEP87 

3.4.2 

4.2  Eigenextraction  Methods 

22SEP87 

3.4.2.1 

4.2.1  Modified  Givens  Method 

22SEP87 

3.4.2.2 

4.2.2  Unsymmetric  Matrix  Techniques 

22SEP87 

3.4.2.3 

4.2.3  Inverse  Power  Eigenextraction  Method  Improvements 

22SEP87 

3.4.2.4 

4.2.4  PEER  Eigenvalue  Analysis  Routine 

SPUN  P00021 
14SEP92 

3.4.3 

4.3  Grid  Point  Sequencer 

SPUN  P00011 
28SEP90 

3.4.4 

4.4  Cray  Single  Precision  Port 

SPUN  P00021 
14SEP92 

Each  of  these  are  described  in  the  following  sections. 

4.1  TIMING  ANALYSIS 

The  purpose  of  this  task  was  to  determine  the  manner  in  which  CPU  resources  are  used  within 
ASTROS  and  to  then  improve  its  performance.  During  2Q88,  UAI  prepared  63  test  problems  that 
had  been  developed  under  the  original  ASTROS  development  contract.  These  problems  formed 
an  initial  baseline  for  timing  analysis. 

The  problems  were  then  executed  using  a  coverage  analysis  tool  that  determines  the  number  of 
times  lines  of  code  are  executed  within  a  subroutine.  The  first  set  of  results  showed  that  the  code 
coverage  of  the  63  test  problems  was  not  adequate  for  insuring  the  quality  of  ASTROS.  The 
development  of  th  formal  test  specification  plan  was  based  on  these  results. 

During  3Q88,  UAI  defined  and  documented  the  Performance  Test  Problem  Library  (PTPL).  This 
library  contained  15  problems  that  cover  all  of  the  analytical  and  design  capabilities  of  ASTROS. 
This  resulted  in  the  Timing  Analysis  Problem  Selection  Report  (CLIN  0001,  CDRL  Sequence  No. 
9)  which  was  delivered  to  COTR  on  2  September  1988. 

The  problems  defined  in  the  Timing  Analysis  Selection  Report  were  then  developed.The  test 
case  design  goal  was  to  develop  problems  which  require  1-2  hours  of  CPU  time.  The  completion 
of  some  of  these  test  cases  required  the  correction  of  several  outstanding  SPRs  and  the  inclusion 
of  the  aerodynamic  enhancements  also  being  performed  (See  Task  2  above). 

One  major  performance  improvement  was  made  to  the  unsymmetric  decomposition  module 
which  comes  into  play  when  solving  problems  that  result  when  ims5Tnmetric  aerodynmamic 
terms  are  added  to  the  stiffness  matrix.  A  problem  that  previous  ran  for  12  hours  ( the  Northrop 
HALE  design  )  was  reduced  to  3  hours  by  correcting  a  misvmderstanding  in  the  algorithm  as 
converted  from  NASTRAN. 
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During  1Q89,  the  development  and  execution  of  the  problems  defined  in  the  Timing  Analysis 
Selection  Report  has  been  completed.  The  table  below  indicates  the  status  of  this  test  problem 
library  at  that  point  in  the  effort. 


Test  Case 

CPU 

Test  Case 

CPU 

PTSTATOl 

0:21 

PTSARO02 

0:31 

PTSTAT02 

0:56 

PTUSAROl 

1:14 

PTMODEOl 

1:38 

PTUSAR02 

1:34 

PTMODE02 

2:22 

PTGUSTOl 

0:40 

PTMODE03 

0:38 

PTBLSTOl 

0:25 

PTTRANOl 

1:21 

PTDESNOl 

1:01 

PTTRAN02 

1:11 

PTDESN02 

2:33 

PTFREQOl 

2:18 

PTDESN03 

1:27 

PTFREQ02 

1:18 

PTDESN04 

2:55 

PTSAROOl 

2:16 

The  test  case  design  goal  was  to  develop  problems  which  require  1-2  hours  of  CPU  time.  By 
2Q89,  several  areas  of  potential  performance  improvement  had  been  identified  and  were  being 
pursued. 


UAI  then  delivered  the  Performance  Test  Problem  library  to  the  COTR  and  requested  that  the 
test  cases  be  executed  using  both  ASTROS  and  COSMIC  NASTRAN  on  the  same  host  computer. 
This  request  has  been  met  and  results  were  delivered  to  UAI  in  the  second  week  of  September 
1989.  The  results  were  then  evaluated  and  a  performance  improvement  plan  formulated. 

During  4Q89,  UAI  made  substantial  performance  gains  in  the  PTPL.  The  most  significant  contri¬ 
bution  to  these  gains  was  the  activation  of  the  different  methods  of  performing  the  computation¬ 
ally  intense  matrix  multiplication  operations.  This  required  writing  a  new  module,  TIMTST, 
which  has  been  installed  into  the  SYSGEN  utility. 

This  new  module  performs  a  number  of  CADDB  operations  which  determine  the  CPU  require¬ 
ments  for  packing  and  impacking  matrices  of  the  different  numeric  types:  real,  single  precision; 
real,  double  precision;  complex,  single  precision;  and  complex,  double  precision.  Not  only  nu¬ 
meric  types  were  considered,  but  also  the  density  of  nonzero  terms  in  the  matrices.  The  module 
has  been  made  a  permanent  part  of  the  SYSGEN  utility,  and  it  will  automatically  determine 
timing  parameters  for  any  ASTROS  host  computer.  The  fifteen  special  timing  constants  are  then 
placed  on  the  system  database  by  SYSGEN  in  an  unstructured  entity  called  TIMCONST. 

Once  the  timing  constants  were  available,  the  MPYAD  module  was  extended  to  use  these  con¬ 
stants.  Testing  was  performed  for  all  of  the  available  MPYAD  methods.  Numerous  errors  were 
uncovered  in  this  code,  which  was  previously  not  exercised.  Many  errors  were  corrected  and  all 
methods  unit  tested.  The  corrected  code  was  then  installed  into  the  development  system  and  the 
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QA  testing  performed  successfully.  The  significant  performance  improvements  achieved  are 
evidenced  in  the  following  table. 


Test  Case 

ASTROS  CPU 

Test  Case 

ASTROS  CPU  1 

Version  4 

Version  5- 

Version  4 

Version  5-  | 

PTSTATOl 

0:18 

0:18 

PTSARO02 

0:29 

0:31 

PTSTAT02 

0:36 

0:22 

PTUSAROl 

2:31 

1:13 

PTMODEOl 

1:48 

0:57 

PTUSAR02 

2:57 

1:34 

PTMODE02 

7:42 

2:57 

PTGUSTOl 

0:55 

1:01 

PTMODE03 

0:21 

0:21 

PTBLSTOl 

0:52 

0:24 

PTTRANOl 

1:21 

0:21 

PTDESNOl 

0:52 

0:33 

PTTRAN02 

0:59 

0:52 

PTDESN02 

1:49 

0:41 

PTFREQOl 

2:18 

2:17 

PTDESN03 

1:44 

0:52 

PTFREQ02 

0:55 

0:45 

PTDESN04 

3:25 

1:21 

PTSAROOl 

2:14 

1:30 

TOTAL 

34:06 

18:50 

The  table  indicates  that  the  full  PTPL  speedup  is  1.8.  Even  more  importantly,  the  design  test 
problems  which  are  of  maximum  importance,  have  a  speedup  of  2.3.  UAI  noted  that  the  irmjor 
impediment  to  having  ASTROS  perform  at  levels  comparable  to  commercially  available  finite 
element  systems  is  the  lack  of  a  grid  point  sequencer,  such  as  the  BANDIT  code  available  in 
COSMIC  NASTRAN,  which  is  built  into  the  system.  It  was  noted  that  without  this  feature, 
further  significant  performance  improvements  would  not  be  possible. 

At  the  ASTROS  semiannual  review  of  26  July  1990,  the  ASTROS  Applications  contractor.  Gen¬ 
eral  Dynamics,  reported  long  running  times  for  large  problems.  This  was  traced  to  the  unsym- 
metric  decomposition  module,  DECOMP,  and  the  companion  forward-backward  substitution 
module  GFBS.  Both  were  originally  adapted  from  COSl^C  NASTRAN  for  ASTROS.  UAI  dis¬ 
covered  a  number  of  severe  inefficiencies  in  this  code.  It  was  believed  that  these  inefficiencies 
were  present  because  the  NASTRAN  system  makes  very  little  use  of  these  modules.  On  the 
other  hand,  their  necessity  when  performing  aerodynamic  design  made  them  crucial  software 
components  of  ASTROS.  UAI  spent  significant  effort  in  studying  this  code  in  order  to  improve 
its  performance.  Initial  studies  indicated  that  the  imsymmetric  cases  rxins  10-20  times  slower 
than  the  same  size  symmetric  solutions.  During  4Q90,  UAI  made  substantial  modifications  to  the 
unsymmetric  decomposition  modules  DECOMP  and  GFBS.  UAI  spent  sigmficant  effort  improv¬ 
ing  the  performance  of  the  module  because,  this  code,  taken  from  COSMIC  NASTRAN,  was 
very  old  and  complex.  Nonetheless,  UAI  was  able  to  achieve  a  2-1  speedup  of  these  modules. 
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4.2  EIGENVALUE  EXTRACTION  METHODS 

Under  this  task,  there  were  four  distinct  work  items: 

■  Modified  Givens  Method 

■  Unsymmetric  Matrix  Techniques 

■  Inverse  Power  Eigenextraction  Method  Improvements 

■  PEER  Eigenvalue  Analysis  Routine 
Each  of  these  is  described  below. 

4.2.1  Modified  Given  Method 

UAI  designed  and  implemented  the  Modified  Givens  method  into  ASTROS  during  1Q89.  This 
method  allows  for  the  solution  of  problems  with  singular  mass  matrices  by  performing  appro¬ 
priate  transformations  on  the  eigenvalues. 

4.2.2  Unsymmetric  Matrix  Techniques 

Begiiming  in  3Q89,  UAI  addressed  the  issues  of  unsymmetric  and  complex  eigenextraction.  The 
goals  were  to  improve  the  Complex  Eigenextraction  module,  and  to  evaluate  the  EISPACK 
eigenextraction  library  for  implementation  into  ASTROS.  UAI  began  with  the  COSMIC  NAS- 
TRAN  complex  eigenvalue  routine,  CEAD,  and  converted  it  to  fimction  properly  for  both  single 
and  double  precision  arithmetic.  The  EISPACK  (LICEPACK)  subroutines  for  solving  complex 
eigenproblems  by  the  Upper  Hessenburg  method  were  then  installed  into  this  module  and  con¬ 
verted  to  ftmction  in  double  precision.  The  module  was  then  tested  in  the  stand-alone  mode. 
Results  of  the  testing  were  identical  to  those  obtained  with  NASTRAN. 

After  a  brief  deferral  of  work  to  concentrate  efforts  on  error  correction  and  performance  im¬ 
provement  prior  to  the  release  of  ASTROS  Version  5,  work  on  the  complex  eigenvalue  routine, 
CEAD,  was  reinitiated  in  1Q90,  and  the  implementation  and  testing  of  this  module  in  ASTROS 
was  completed.  Eight  test  cases  used  by  NASTRAN  were  executed  in  ASTROS  using  direct 
matrix  input.  These  test  cases  resulted  in  the  same  answers  as  NASTRAN.  Additionally,  this 
module  was  significantly  improved  over  the  original  NASTRAN  code  used  as  a  software  re¬ 
source.  Many  errors  were  corrected,  the  new  Upper  Hessenberg  method  from  the  well-known 
EISPACK/LICEPACK  library  was  installed,  and  full  support  for  single  and  double  precision 
computation  was  provided. 

The  complex  eigenvalue  routine  was  then  installed,  and  released,  in  ASTROS  Version  6. 

4.2.3  Inverse  Power  Improvements 

Beginning  in  1Q89,  UAI  corrected  the  previously  nonfunctional  Inverse  Power  eigenvalue  ex¬ 
traction  method.  This  method  is  used  to  extract  a  small  number  of  frequencies  from  a  large 
model.  It  is  therefore  useful  in  reducing  the  cost  of  large  multidisciplinary  design  problems. 
Additionally,  UAI  has  improved  this  method  to  perform  the  Sturm  Sequence  Checks  (SINV) 
which  improve  the  reliability  of  the  method  by  insuring  that  all  eigenvalues  within  the  specified 
range  have  been  foimd. 

The  charts  below  presents  the  results  of  all  current  ASTROS  eigenmethods  for  a  simple  test 
problem.  The  problem  is  a  cantilever  beam  of  length  300  units  which  is  modelled  with  BAR 
elements.  Test  1  divided  the  beam  into  200  segments  which  resulted  in  a  problem  size  of  200 
degrees-of-freedom.  For  Test  2,  the  number  of  segments  was  increased  to  create  3000  degrees-of- 
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freedom.  The  Givens  and  Modified  Givens  runs  for  Test  2  used  static  condensation  to  reduce  the 
problem  to  200  degrees-of-freedom  prior  to  solution.  The  first  five  axial  vibration  modes  are 
computed  using  each  of  the  methods.  The  results,  compared  with  the  theoretical  values,  and  the 
ASTROS  CPU  time  for  each  method,  are  given  in  the  table  below.  Note  that  the  results  are  in 
excellent  agreement.  _ 


TEST  1 :  200  DEGREES-OF-FREEDOM  I 

MODE 

NUMBER 

Eigenvalues,  Hz 

THEORY 

GIVENS 

MODIFIED 

GIVENS 

SINV 

GDR 

1 

2.74 

2.74 

2.74 

2.74 

2.74 

2 

24.7 

24.7 

24.7 

24.7 

24.7 

3 

68.5 

68.5 

68.5 

68.5 

68.5 

4 

134.3 

134.3 

134.3 

134.3 

134.3 

5 

222.1 

222.0 

222.0 

222.0 

222.0 

CPU  (Sec) 

N/A 

69 

133 

229 

91 

TEST  2:  3000  DEGREES-OF-FREEDOM 


MODE 

NUMBER 

Eigenvalues,  Hz 

THEORY 

GIVENS 

MODIFIED 

GIVENS 

SINV 

GDR 

1 

2.74 

2.74 

2.74 

2.74 

2.74 

2 

24.7 

24.7 

24.7 

24.7 

24.7 

3 

68.5 

68.5 

68.5 

68.5 

68.5 

4 

134.3 

134.3 

134.3 

134.3 

134.3 

5 

222.1 

222.1 

222.1 

222.1 

222.1 

N/A 

2025 

1995 

4209 

2421 

4.2.4  PEER  Eigenanalysis  Routine 

The  installation  of  the  PEER  eigensolver  was  completed  during  1Q93.  The  PEER  method  is  a 
range  solver;  that  is,  it  extracts  a  specified  number  of  eigenvalues  in  a  given  frequency  range. 
This  code,  provided  by  the  Air  Porce,  was  adapted  from  that  available  in  the  COSMIC  NAS- 
TRAN  program. 

Preliminary  testing  results  indicate  that  this  method  can  result  in  improved  performance  for 
ASTROS  problems  requiring  the  extraction  of  modes.  This  is  primarily  due  to  savings  that  can 
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be  achieved  by  eliminating  the  somewhat  costly  static  condensation  that  is  generally  required 
when  using  the  GIVENS  method  which  extracts  all  the  roots  of  a  system. 

The  table  below  compares  the  CPU  times  for  the  available  ASTROS  eigenextraction  methods  as 
applied  to  tiie  performance  test  problem  PTMODE. 


EIGENMETHOD 


GIVENS 


CPU  for 

Eigenextraction 


24.4  sec 


Total 

CPU 


226.2  sec 


Notes 


Reduced 


INVERSE  POWER 


69.3  sec 


90.6  sec 


No  reduction 


PEER 


44.3  sec 


65.3  sec 


No  reduction 


In  the  case  of  GIVENS,  although  the  CPU  time  for  the  actual  eigenextraction  is  small,  the  total 
job  CPU  is  high  because  of  the  cost  of  the  reduction  procedure.  It  thus  appears  that  when  only 
some  eigenvalues  are  required,  the  PEER  method  will  provide  a  significant  computational  ad¬ 
vantage.  This  new  method  is  also  faster  than  the  inverse  power  method. 


4,3  GRID  POINT  SEQUENCER 


During  1Q91,  UAI  performed  all  of  the  required  coding  modifications  and  testing  for  the  Grid 
Point  Sequencer,  including  changes  to  the  baseline  sequencer  module  which  was  derived  from 
the  BANDIT  code  used  in  COSMIC  NASTRAN.  This  important  new  feature  was  delivered  to 
COTR  in  an  interim  release  of  ASTROS,  designated  Version  7.5,  in  late  May  1991. 

4.4  CRAY  SINGLE-PRECISION  PORT 


This  task,  added  in,  required  the  full  and  complete  conversion  of  the  standard  ASTROS  system 
to  function  properly  on  the  Cray  Y-MP  series  of  computers.  This  required  that  every  ASTROS 
subroutine  be  analyzed  to  determine  the  changes  required  to  properly  handle  conflicting  re¬ 
quirements  of  single  and  double  precision  arithmetic.  Of  particular  importance  was  the  handling 
of  dynamic  memory  pointers. 

Work  began  in  3Q92,  when  all  1796  ASTROS  subroutines  were  analyzed  and  it  was  determined 
that  387  of  these  routines  had  double  precision  local  variables,  arguments,  or  variables  in  com¬ 
mon  blocks.  Next,  for  each  of  these  routines  it  was  necessary  to  manually  review  every  Une  of 
code.  Then,  a  decision  was  made  as  to  the  appropriate  course  of  action  to  be  taken.  There  are 
two  basic  approaches  to  resolving  these  issues:  to  create  a  new  subroutine  in  which  all  pre¬ 
viously  double  precision  variables  are  changed  to  single  precision;  or  to  include  special  code 
within  a  routine  which  determines  the  host  machine  precision  and  performs  the  appropriate 
operation.  The  choice  of  approaches  is  somewhat  subjective,  but  UAI,  in  their  experience  with 
large  software  system  development,  determined  that,  in  general,  routines  which  are  primarily 
computational  in  nature  are  recast  as  two  separate  versions.  On  the  other  hand,  routines  which 
are  drivers,  i.e.  they  set  up  an  environment  and  then  call  other  routines  which  perform  the  actual 
operations,  are  generally  converted  using  in-line  code. 

The  next  major  work  item  required  the  review  and  modification  of  the  matrix  utilities  including 
algebraic  routines,  manipulative  routines,  and  solvers.  UAI  determined  that  the  most  effective 
manner  in  which  to  perform  this  activity  and,  at  the  same  time,  to  increase  the  robustness  of  the 
ASTROS  system,  was  to  replace  all  ASTROS  matrix  routines  with  code  from  UAI's  proprietary 


UAI/NASTRAN  system.  These  routines  have  been  fimctioning  correctly  for  many  years  in  the 
commercial  marketplace  in  both  single  and  double  precision  versions.  (Please  note  that  while 
UAI  donated  diese  routines  to  the  benefit  of  the  government,  they  do  not  contain  all  of  UATs 
proprietary  developments.  Further,  any  subsequent  maintenance  or  enhancement  is  the  respon¬ 
sibility  of  the  government  under  this  effort). 

All  of  the  modified  software  was  then  moved  to  the  Cray-YMP  computer  in  Minneapolis.  The 
system  was  built  and  a  clean  QA  performed.  Next,  the  first  step  of  optimization  was  performed. 
Shown  below  is  a  table  comparing  computer  nm  time  between  UATs  MicroVax  HI  and  the  Cray 
Y-MP.  The  first  case  on  the  Cray  shows  the  results  of  the  native  port,  i.e.  no  compiler  optimiza¬ 
tion,  and  the  second,  the  results  after  performing  compiler  optimization. 


Machine 

CPU  Time  (Sec) 

DEC  MicroVax  III 

781 

Cray  Y-MP  (No  Optimization) 

133 

Cray  Y-MP  (Optimization) 

64 

The  conversion  task  was  completed  in  4Q94.  There  were  three  major  areas,  described  below,  that 
required  significant  effort  under  this  task. 

4.4.1  Problems  with  MicroDOT  Code 

The  most  insidious  problem  encountered  was  a  numerical  instability  that  occurred  in  some  test 
cases,  most  notably  the  F20  model.  The  problem  was  traced  to  the  MicroDOT  optimization  code. 
The  routines  in  this  module  contained  a  very  large  number  of  hard-coded  constants,  e.g.  10  , 
-1x10^^,  1x10’^,  etc.,  which  appear  to  have  been  determined  heuristically  during  the  develop¬ 
ment  of  this  code.  These  constants  were  clearly  not  intended  for  use  on  the  Cray  computer.  UAI 
had  to  identify  all  of  these  situations  and  analyze  their  impact  on  the  optimization.  A  number  of 
changes  were  made  which  led  to  correct  results  for  test  cases  which  previously  had  erroneous 
answers. 

This  exercise  pointed  out  the  potential  for  recurring  instabilities  for  new  models  which  are 
analyzed  and  designed  with  ASTROS.  The  symptoms  will  probably  be  indicated  by  intermittant 
failure  of  jobs  to  converge.  As  a  result,  it  may  be  required  to  perform  more  analysis  in  the 
MicroDOT  module  in  the  future. 

4.4.2  Performance  Issues 

Although  this  task  did  not  include  code  optimization  for  performance  on  the  Cray,  it  did  include 
the  analysis  and  modiHcation  of  the  machine-dependent  library.  This  library  required  modifica¬ 
tions,  some  major,  in  order  to  bring  the  Cray  performance  into  the  acceptable  range.  The  pri¬ 
mary  problems  encountered  were  in  routines  which  perform  character  manipulation.  These 
were  corrected  and  improved. 

4.4.3  ICE 

The  Interactive  CADDB  Environment,  ICE,  was  also  fully  implemented  on  the  Cray. 
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The  Cray  version  of  ASTROS  was  delivered  with  the  Version  10.0  ASTROS  system.  As  discussed 
above,  optimization  of  ASTROS  other  than  that  performed  by  the  Cray  compiler  was  beyond  the 
scope  of  this  task.  The  final  performance  measure,  comparing  the  Cray  version  to  UAI's  IBM 
RS6000/560  is  presented  in  the  following  table. 


PERFORMANCE 
TEST  CASE 

Cray  YMP 

IBM/560 

SPEEDUP 

(IBM/CRAY) 

ptblstOl . d 

68 

77.5 

1.14 

ptdesnOl . d 

66.3 

103.3 

1.56 

ptdesn02 . d 

49 

63.9 

1.30 

ptdesnOS . d 

90.3 

120.1 

1.33 

ptdesn04 . d 

143.0 

252.7 

1.77 

ptfreqOl . d 

619.0 

637.2 

1.03 

ptfreq02 . d 

91.2 

81.7 

0.90 

ptgustOl .d 

80.7 

177.7 

2.20 

ptinodeOl .  d 

78.4 

101.1 

1.29 

ptmode02 . d 

98.4 

231.7 

2.35 

ptmodeOS . d 

44.1 

46.4 

1.05 

ptsaroOl . d 

144.8 

231.1 

1.60 

ptsaro02 . d 

58.2 

138.6 

2.38 

ptstatOl . d 

25.1 

27.1 

1.08 

ptstat02 . d 

101.1 

79.2 

0.78 

pttranOl . d 

79.9 

90.8 

1.14 

pttran02 . d 

102.6 

99.7 

0.97 

ptusarOl . d 

114.3 

208.3 

1.82 

ptusar02 , d 

Problem  fails  on  CRAY  due  to  numerical  instability 

SUMMARY 

2054.4 

2768.1 

1.35 

The  range  of  speedup  is  0.78  to  2.38.  Optimization  of  the  code  to  take  advantage  of  the  vector 
power  of  the  Cray  could  improve  this  relative  performance. 
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TASK  5.  QUALITY  ASSURANCE 


Under  this  task,  UAI  was  to  perform  six  subtasks.  These  are: 


Contract 

Ref. 

TASK  NUMBER  AND  DESCRIPTION 

Effective 

Date 

3,5.1 

5.1  Configuration  Management 

22SEP87 

3.5.1.1 

5.1.1  Software  Development  Plan 

22SEP87 

3.5.1 .2 

5.1.2  Configuration  Identification 

22SEP87 

3.5.1 .3 

5.1.3  Configuration  Control 

22SEP87 

3.5.2 

5.2  Testing 

22SEP87 

3.5.3 

5.3  Error  Correction 

22SEP87 

5.1  CONFIGURATION  MANAGEMENT 

The  purpose  of  Configuration  Management  is  to  control  the  software  development  process.  To 
accomplish  this,  three  subtasks  were  performed  under  this  effort.  These  are  described  in  the 
following  sections. 

5.1 .1  Software  Development  Plan 

The  purpose  of  this  task  was  to  formulate  a  complete  Software  Development  Plan  for  the  en¬ 
hancement  of  ASTROS.  The  development  of  this  plan  began  in  3Q87  and  was  completed  in 
1Q88.  The  plan  was  based  on  the  general  requirments  and  guidelines  for  software  development 
that  are  consistent  with  DOD-STD-2167  and  customized  for  ASTROS.  The  goal  of  the  plan  was 
to  specify  the  methodology  to  be  used  in  development  of  the  system  to  insure  quality.  A  prelimi¬ 
nary  draft  of  this  plan  was  delivered  to  COTR  on  9  March  1988. 

5.1.2  Configuration  Identification 

Under  this  task,  UAI  identified  all  of  the  Computer  Software  Configuration  Items  (CSCI)  for  the 
ASTROS  system.  This  required  the  identification  of  the  specific  functions  of  the  825  subroutines 
that  comprised  ASTROS  at  the  start  of  this  contract.  The  CSCTs  were  defined  during  2Q88  and  a 
list  of  them  was  provided  in  the  R&D  Status  Report  for  that  period. 

5.1.3  Configuration  Control 

Under  this  task,  UAI  used  the  Source  Code  Configuration  System  (SCCS)  available  on  the  GFE 
DEC  computer  as  a  configuration  management  tool.  This  required  the  design  and  implementa¬ 
tion  of  31  Ultrix  script  files  which  were  used  to  perform  various  development  tasks.  Such  tasks 
included:  retrieving  information  about  CSCTs;  comparing  different  CSCI  versions;  adding  and 
deleting  CSCI  items;  and  building  various  test  systems  during  a  specific  development  activity. 
These  activities  were  also  accomplished  during  2Q88  and  a  list  of  the  procedures  was  provided 
in  the  R&D  Status  Report  for  that  period. 
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5.2  TESTING 


The  purpose  of  this  task  was  to  perform  comprehensive  testing  of  the  baseline  ASTROS  software 
system  and  to  develop  methods  to  improve  such  testing.  The  task  began  in  2Q88  with  the 
execution  of  the  63  demonstration  problems  developed  under  the  original  ASTROS  contract. 
UAI  executed  these  using  a  coverage  analysis  tool  wtdch  determines  how  many  times  each  line 
of  code  in  a  program  executes.  A  list  of  the  results  of  this  testing  were  presented  in  the  R&D 
Status  Report  for  this  period. 

The  results  of  the  initial  testing  indicated  that  many  routines  were  being  inadequately  tested.  To 
address  this,  UAI  developed  a  formal  test  specification  plan  as  part  of  the  overall  Test  Problem 
selection.  The  intent  was  to  achieve  a  90%  coverage  rate  for  the  entire  ASTROS  system.  During 
3Q88,  the  detailed  test  plans  were  formulated  for  each  of  the  89  ASTROS  CSCI's.  These  specifica¬ 
tions,  as  well  as  descriptions  of  147  beta  test  problems.  These  were  delivered  to  COTR  on  10 
October  1988  as  the  Beta  Test  Plan  Selection  Report  (CDRL  CLIN  0001,  Seq.  No.  10). 

During  4Q88,  UAI  developed  the  test  problems  which  satisfy  the  requirements  given  in  the  Beta 
Test  Plan  Problem  Selection  Report.  At  the  end  of  the  reporting  period,  167  test  cases  had  been 
developed  and  executed  using  ASTROS  Version  2.  Detailed  coverage  data  was  maintained.  The 
chart  below  compares  the  current  coverage  levels  of  these  problems  to  that  of  the  original  64 
problems  used  for  QA  testing  of  the  system. 
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Total  system  coverage  for  this  test  suite,  not  including  any  of  the  original  test  problems,  now 
exceeds  70%. 

UAI  continued  the  development  and  execution  of  the  test  problems  specified  in  the  Beta  Test 
Plan  Problem  Selection  Report  during  1Q89  and  2Q89,  at  which  point  total  system  coverage  for 
this  test  suite,  not  including  any  of  the  original  test  problems,  exceeded  83%.  Additional  test 
problems  have  been  developed  to  cover  the  new  and  modified  capabilities  reported  in  the  other 
sections  of  this  report. 

During  3Q89,  UAI  completed  the  prototype  of  the  automated  QA  program  suitable  for  the 
regression  testing  of  future  releases  of  ASTROS. 
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5.3  ERROR  CORRECTION 


Under  this  task,  UAI  corrected  errors  in  the  ASTROS  software,  including  those  reported  by 
external  user's,  and  those  discovered  during  testing  under  5.2  above.  In  addition  to  correcting 
errors,  UAI  developed  an  Ettot  Eo^  which  has  been  distributed  to  the  current  user  community 
since  ASTROS  Version  3.  This  log  includes  the  descriptions  of  the  errors  that  have  been  reported 
and,  where  possible,  the  manner  in  which  a  user  may  avoid  them. 

This  task,  which  lasted  for  the  duration  of  the  contract  effort,  resulted  in  the  correction  of  many 
hundreds  of  errors.  The  details  of  many  of  these  were  included  in  R&D  Status  Reports,  and  are 
too  voluminous  to  repeat  here. 
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TASK  6.  POST-PROCESSOR  INTERFACES 


Under  this  task,  UAI  was  to  perform  six  subtasks.  These  are: 


Contract 

Ref. 

TASK  NUMBER  AND  DESCRIPTION 

Effective 

Date 

3.6.1 

6.1  OFP  Interfaces 

22SEP87 

3.6.1. 1 

6-1.1  New  Output  Data 

22SEP87 

3.6.1. 2 

6.1.2  New  Bulk  Data 

22SEP87 

1  3.6.2 

6.2  CADDB  Interface 

6.1  OFP  INTERFACES 

Under  this  task,  UAI  made  modifications  and  enhancements  to  the  OFP  module  and  related 
Solution  Control  directives  in  two  areas.  First,  the  range  of  data  that  can  be  selected  for  output  to 
a  punch  file  was  enlarged.  Second,  the  option  to  generate  a  new  Bulk  Data  deck  was  imple¬ 
mented. 

6.1.1  New  Output  Data 

Under  this  subtask,  Northrop  and  UAI  modified  ASTROS  so  that  a  user  can  direct  additional 
data  to  a  pimch  file.  All  of  these  additions  were  made  during  3Q90  and  4Q90,  and  they  were 
released  in  Version  7.0  of  ASTROS  in  February  1991. 

6.1.2  New  Bulk  Data 

Under  this  task,  UAI  added  a  new  capability  to  OFP  for  the  user  to  direct  the  generation  of  new 
Bulk  Data  deck  which  represents  the  design  found  by  ASTROS  during  any  cycle  of  optimization. 
This  feature,  which  allows  a  new  data  file  to  be  created  from  any  design  iteration,  was  released 
in  Version  9.0  of  ASTROS  in  August,  1992. 

6.2  CADDB  Interface 

Under  this  task,  UAI  developed  the  Interactive  CADDB  Interface  (ICE).  This  separate  interactive 
program  was  designed  to  allow  the  ASTROS  CADDB  database  to  be  queried  by  users.  The 
language  selected  was  the  Structured  Query  Language,  SQL,  which  is  the  standard  interface  to 
relational  databases.  Work  on  this  task  began  before  the  arrival  of  the  GFE  computer.  During 
1Q88  all  design  specification  documents  and  the  Critical  Design  Review  were  complete.  The 
preliminary  draft  of  the  Ice  User's  Manual  was  delivered  to  COTR  on  8  March  1988. 

The  first  version  of  ICE  was  completed  during  2Q88  and  demonstrated  to  the  WL  team  at  the 
Quarterly  Review  held  on  23  June  1988  at  WPAFB.  The  ICE  Interface  was  completed  during 
3Q88  and  delivered  to  COTR  along  with  the  ICE  User's  Manual,  which  was  reviewed  and 
pubhshed  as  AFWAL-TR-88-3060.  ICE  was  officially  released  in  Version  3.0  of  ASTROS  in 
January  1989. 
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SEMI-ANNUAL  REVIEWS 


The  following  table  summarizes  the  semi-annual  contract  reviews  that  were  held,  and  participa¬ 
tion  in  other  ASTROS-related  activities,  during  the  contract  effort. 


REVIEW/ 

ACTION 

LOCATION/DESCRIPTION 

DATE 

INITIAL 

CONTRACT  SIGNED 

22SEP87 

KICKOFF 

WPAFB 

210CT87 

1 

WPAFB 

23JUN88 

2 

WPAFB 

4NOV88 

3 

WPAFB 

18MAY89 

4 

WPAFB 

06FEB90 

5 

WPAFB 

26JUL90 

6 

WPAFB 

21FEB91 

— 

ASTROS  Training  Course,  Cray  Research 

JUN91 

_ 

ASTROS  Training  Course,  Phillips  Laboratory  (CA) 

FEB92 

_ 

ASTROS  Training  Course,  WPAFB 

FEB93 

Informal 

Meeting  at  SDM,  La  Jolla,  CA 

20APR93 

_ 

ASTROS  Training  Course,  Georgia  Tech 

16MAY94 

ASTROS  Training  Course,  WPAFB 

08AUG94 

— 

ASTROS  User  Group  Meeting  (FL) 

SEP94 
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CDRL  ITEMS 


The  following  chart  summarizes  the  Contract  Data  Requirements  List  (CRDL)  items  for  the 
contract  effort.  Note  that  CDRL  Seq.  Nos.  from  1  through  7  are  standard  Quarterly  Reports  and 
other  contract  information.  The  following  table  summarizes  those  items  which  represent  con¬ 
tract  deliverables. 


CLIN 

CDRL 
Seq.  No. 

DESCRIPTION 

DATE  1 

0001 

8 

ASTROS  Enhancements  Software  Development  Plan 

03NOV88 

0001 

9 

Timing  Analysis  Problem  Selection  Report 

02SEP88 

0001 

10 

Beta  Test  Problem  Selection  Report 

10OCT88 

0001 

11 

Software  Theoretical  Manual 

16JUN95 

0001 

12 

Software  Programmer's  Manual 

04JUN93 

0001 

13 

Software  User's  Manual 

13MAY93 

0001 

14 

Final  Report 

16JUN95 

0001 

15 

Software  Programmer's  Manual  (Revised) 

16JUN95 

0001 

16 

Software  User's  Manual  (Revised) 

16JUN95 

0002 

1 

Computer  Software  Product 

See  Next 
Section 

0002 

2 

Interactive  CADDB  Interface 

10OCT88 
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ASTROS  SYSTEM  RELEASE 


Over  the  course  of  the  ASTROS  Enhancements  contract  effort,  UAI  generated  13  releases  of  the 
software.  Eleven  of  these  were  general  releases,  and  two  were  special  releases  which  were 
requested  by  COTR.  The  following  table  provides  a  summary  of  these  systems  and  a  brief 
description  of  their  technical  highlights. 


VERSION 

RELEASE 

DATE 

HIGHLIGHTS 

2 

JUN88 

First  UAI  release  after  Configuration  Management  implementation. 

3 

JAN89 

Release  of  the  Interactive  CADDB  Enivironment  and  major  changes  to 
design  variable  linking  and  constraint  definition. 

4 

JUN89 

Version  4  included  the  TRIAS  element  and  the  correction  of  known 
problems  in  the  QUAD4  element.  Additionally,  the  two  new 
eigenextraction  methods  were  released  and  the  Generalized  Dynamic 
Reduction  (GDR)  feature  was  improved.  A  new  document,  called 
ASTROS  System  Release  Notes,  was  introduced  with  this  release.  These 
notes  provide  a  vehicle  for  disseminating  information  to  the  user 
commtmity  describing  the  highlights  of  the  new  version  and  providing 
interim  user  documentation  modifications. 

5 

FEB90 

The  key  features  for  Version  5  were  the  aeroelastic  improvements 
performed  by  UAI's  subcontractor  Northrop.  I 

6 

JUL90 

New  rigid  elements,  aeroelastic  constraints,  and  a  new  CEAD  module 
for  complex  eigen  analysis. 

7 

FEB91 

New  OFF  Interfaces,  Optimality  Criteria  methods,  and  the  Grid  Point 
Weight  Generator. 

7.5 

MAY91 

This  was  an  interim  system  that  included  a  pre-release  of  the  Grid  point 
sequencer. 

8 

AUG91 

Final  version  of  the  Grid  point  sequencer  and  completely  redesign 
stress/ strain  design  constraints. 

9 

AUG92 

New  Bulk  Data  pimch  feature  and  Grid  point  force  output. 

10 

JUN93 

New  FEER  eigenanalysis  method,  laminate  constraints,  rigid  body 
strain  energy  checks,  and  the  release  of  the  CRAY  UNICOS  version. 

10.5 

SEP93 

Error  corrections  and  prerelease  of  AUTOSPC  feature  at  the  special 
request  of  COTR  to  support  the  FISCT  program. 

11 

MAY94 

Key  features  included  AUTOSPC  and  the  panel  and  column  buckling 
capabilities. 

12 

JUN95 

Final  developments  including  bending  sensitivities  and  user  defined 
objective  and  constraint  functions. 
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CONTRACT  MODIFICATIONS 


During  the  course  of  this  effort,  the  were  two  major  contract  modifications.  These  are  summa¬ 
rized  in  the  following  sections. 

First  Redirection  of  Effort 

On  22  June  1989,  UAI  received  a  formal  request  from  the  Contracting  Officer,  to  offer  a  proposal 
to  the  Air  Force  for  modifying  the  current  contractual  effort.  The  Air  Force  wished  to  modify 
Task  3,  Optimality  Criteria,  due  to  the  potential  availabilty  of  GFP,  such  that  additional  effort 
could  be  expended  on  Task  1,  Finite  Element  Library,  and  Task  2,  Aeroelasticity.  UAI  responded 
to  this  request  on  1  July  1989. 

On  1  September  1989,  UAI  received  a  summary  of  the  changes  proposed  by  the  Air  Force  for  this 
modification.  After  several  iterations,  UAI  received  a  Redirection  of  Effort  and  Extension  of 
Performance  Period  on  28  September  1990,  This  change  added  three  new  tasks  to  the  contract 
effort: 


■  Task  3.1  Generalized  Stiffness  Constraint 

■  Task  3.2  Stress/ Strain  Constraints 

■  Task  4.3  Grid  Point  Sequencer 

and  extended  Task  5.3,  Error  Correction.  Addtionally,  delivery  dates  for  CDRL  items  were 
modified. 

Second  Redirection  of  Effort 

On  9  September  1992,  UAI  received  a  Redirection  of  Effort  and  Change  of  Performance  Period. 
This  change  added  eight  new  tasks  to  the  effort: 

■  Task  1.5  Automatic  SPC  Generator 
H  Task  2.11  FFT  With  Random  Input 

■  Task  3.3  Bending  Element  Sensitivity 

■  Task  3.4  Buckling  Optimization 

M  Task  3.5  User-defined  Constraint  and  Objective  Functions 

■  Task  3.6  Composite  Laminate  Constraints 

■  Task  4.2.4  PEER  Eigenvalue  Analysis 

■  Task  4.3  Cray  Single  Precision  Port 

In  addition.  Task  5.3  Error  Correction  was  extended  for  the  duration  of  the  new  effort. 
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